Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.
This invention relates to the field of computer graphics, and more specifically, to saving the state of a graphics pipeline when processing an image for display to a computer monitor.
Generally, the field of three-dimensional (3D) computer graphics is concerned with generating and displaying 3D objects in a two-dimensional (2D) space, such as a display screen. This is accomplished by converting information about 3D objects into a bit map that is displayed. This process is called rendering, a multi-part process by which a computer turns an application model description of an image into a screen image. The basic idea is that the processing of information in three-dimensional computer graphics occurs in a series of stages in a graphics pipeline, where each stage generates results for a successive stage.
The process starts with an application model for describing an object using three-dimensional coordinates.(x, y, z), where the object is defined by large numbers of basic geometrical shapes called primitives that define the shape of components of the object. Examples of primitives that make up an object include triangles, lines, dots, circles, ellipses, arcs, texts, polylines, and polygons. In addition to primitives, an application model stores object attributes such as size, color, line width, and surface texture, as well as connectivity relationships and positioning data that describe how the components fit together. In addition to primitives and attributes, geometric transformations for scaling, rotating, and positioning components, and for specifying how components are to be viewed in 3D, for example, may also be specified.
The application model for a given object is created by an application program, and stored in an application database. Using a graphics API (application programming interface), a series of graphics output commands that contain both a detailed geometric description of what is to be viewed and the attributes describing how the objects should appear, the application program converts the application model to a sequence of commands, which are then processed by a graphics pipeline to generate a view of the model. The graphics API typically consists of a set of output subroutines corresponding to the various primitives, attributes, and other elements, which are all collected in a graphics package that can be called from high-level languages such as C, Pascal, or LISP.
Data in the application database may include geometric data or state information. Geometric data defines primitives, such as triangles, lines, or dots. For example, geometric data may include vertices. State information comprises data that controls a particular value or mode, and is stored in a memory, such as registers. For example, state information may set the current depth cue color to black, or disable blending of pixel data into the frame buffer.
When a graphics system switches from an application running in one window (one context) to an application running in another (second context), context state information for one application must be saved at various stages in the graphics pipeline while context state information for the other application is restored. To save and restore applications in this fashion, some existing systems require that the entire graphics pipeline for a first context be flushed in order to obtain the current state of the first context prior to a second context being restored. Once the pipeline is drained, its state is then saved to a local memory, and context state information for the second context can be restored or loaded. One drawback to this method is the lagtime in waiting for the pipeline to drain before the state of another context can be restored.
One solution to this problem is to keep a copy of context state information in software or in registers at the top of the hardware graphics pipeline, which would avoid the need to flush the graphics pipeline. However, this solution either requires a significant amount of additional software code to keep track of all current register values, or requires additional storage registers and register address decode logic to save a copy of each register before it is sent into the graphics pipeline. A drawback of this method is that software is needlessly complicated, and extra storage registers and decode logic are required. Furthermore, an alternate data path must be used to save first context state information while the second context state information is restored.